iT邦幫忙

2026 iThome 鐵人賽

DAY 16
0

前言

昨天把容器選好了:EDA 裡用 TCL 用 dict 打包好,再轉變成 JSON。今天要定義怎樣一份才能算合格的資料

兩份檔案,兩件不同的事

執行目錄裡只有兩種資料

第一種是 階層檔,放在 dist/design 下,一份檔對應一個製程加一個專案。它回答:這個專案裡有哪些 block、誰是誰的上層 Block。沒有它我們就不知道這次專案倒底跑了什麼,彼此之間的階層關係是什麼

第二種是 上傳檔,放在 dist/uploads/[製程]/[專案] 下,一份檔對應一次 block 的 flow run。它回答:這次跑的是哪個專案的哪顆 block、APR 還是 ECO、版本叫什麼、父親是誰、KPI 與檢查項結果。沒有它,階層關係會還在,但結果都會是空的

  design/                         uploads/[製程]/[專案]/
  階層檔 一份 = 一個專案             上傳檔 一份 = 一次 run
  ┌─────────────────────┐        ┌─────────────────────┐
  │[製成]_[專案名稱].json|        │ 檔名可很長、可帶 %)  │
  │ 這專案有哪些 block   │        │ 哪顆、APR 還是 ECO   │
  │ 誰是誰的上層         │        │ 父親是誰、指標、檢查  │
  └──────────┬──────────┘        └──────────┬──────────┘
             │                              │
             └──────── 對上 ─────────┘
                       製程 · 專案 · block 名

互認規則:對上才會有畫面

把兩邊湊一起,靠的是三個關鍵:製程、專案、block 名稱。

  階層檔    N4_TUTORIAL.json              上傳檔裡的欄位
  檔名前半  N4          <──必須相同──>  製程(檢查或設計資訊)
  檔名後半  TUTORIAL     <──必須相同──>  project
  block 名稱 tut_cpu     <──必須相同──>  設計名

階層檔:檔名就是身分

階層檔的檔名是有規則的 --> 製程_專案.json。伺服器用這條規則拆出 process、project

檔案內容是一棵巢狀的 block 樹。在最上面的節點放 top 字串,專案表會多一列標成頂層,它會永遠在最上面,代表這個專案的最頂層,接著把所有 partition 放在 subblocks 裡;直到沒有 subblock,就用空字串表示「這層沒有再往下」。

你可以試著在 dist/design/ 新增一個 N4_TUTORIAL.json 看看

{
    "N4_TUTORIAL": {
      "top": "tutorial_chip",
      "subblocks": [
        { "tut_cpu": "" },
        {
          "tut_sys_top": {
            "subblocks": [
              { "tut_mem": "" }
            ]
          }
        }
      ]
    }
  }

接著 整頁 F5。N4 下面應該會多一張 TUTORIAL

https://ithelp.ithome.com.tw/upload/images/20260825/20127932qmrXLtmAlr.png

上傳檔:一個 run 的身分,加上一堆資料

上傳檔的內容規矩,除了對資料的分析部分之後再說明,通用的規則是

這些檔案只有在點開專案卡片的那瞬間,才會載入該專案下的所有資料

JSON 欄位 必填? 規則
upload_id 建議有 內部 id 優先用它;沒有則用 file_name,再沒有用檔名
file_name 當別名,也用來對 father
project 實務上要有 必須對上 design 階層的 project 名,否則畫面配不到 block
design item.design_info.data.design_name 沒有時,用 design@ 前半當 block
stage 流程階段字串(如 cts);小寫 eco 會被歸成 ECO
version 版本頁 / Summary 顯示
uploader / owner 元資料顯示
upload_date 建議有 用來比「最新一筆」;格式實務上是 YYYY.MM.DD.HH:MM:SS
runtime 顯示用
userinfo 原樣保留
father 譜系父節點;空則當 root
item 這就是你主要要上傳的資料 注意裡面 item.design_info.data.process_node 跟 item.design_info.data.design_name 要對上階層檔才看得到東西

item 才是本體,裡面塞入 APR 會想看的各式資訊。每一區常見的形狀是底下再包一層 data,你可以在裡面填上任何你想看的資訊,後面的重點都是分析跟呈現這區塊的資料

{
  "upload_id": "DEMO%CPU@T01010001%demo.user%place%20260825%",
  "file_name": "DEMO%CPU@T01010001%demo.user%place%20260825%",
  "project": "DEMO",
  "design": "CPU@T01010001",
  "stage": "place",
  "version": "20260825",
  "uploader": "demo.user",
  "owner": "demo.user",
  "upload_date": "2026.08.01.10:00:00",
  "father": "",
  "runtime": "00:01:00",
  "item": {
    "design_info": {
      "data": {
        "design_name": "CPU",
        "process_node": "N4"
      }
    },
    "drc": { "data": { "all": { "value": 0 }, "short": { "value": 0 } } }
  }
}

小結

介紹完整個專案的靜態資料連結,跟必填的欄位


上一篇
【Day 15】 資料結構選擇與 TCL 實戰:設計人避不了的必修課
下一篇
Day 17 | 從檔案清單到畫面:讀檔整理如何把檔變成一頁
系列文
打造 APR Engineer 的生產力平台,從 Flow Tracer 到 SignOff DashBoard 的落地實戰20
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言